home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 671 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.6 KB

  1. From: bousch@suntopo.matups.fr (Thierry Bousch)
  2. Subject: Re: two bugs fixed in ramfs 1.4
  3. Date: Mon, 29 Nov 1993 23:22:54 +0100 (MET)
  4.         Vincent.Pomey@linn.fidonet.org (Vincent Pomey)
  5. In-Reply-To: <m0p403e-0000czC@sdf.lonestar.org> from "Evan Langlois" at Nov 28, 93 10:17:00 pm
  6.  
  7. Hello Evan,
  8.  
  9. > ========================  quote =======================
  10. > You should apply the following patch to ramfs.c to upgrade it from
  11. > version 1.4 to version 1.5.  It fixes these two bugs.
  12. > =======================================================
  13. > I believe there is another bug.  STZIP Fseek's to the end of the
  14. > file to read the header information at the end.  STZIP is not able
  15. > to read the header information from any file on RAM FS.  I believe
  16. > its a problem of RAMFS.
  17.  
  18. increasing the debug level in MiNT reveals that stzip issues a
  19.  
  20.     Fseek(-2048,2) on handle 6
  21.     
  22. which should hopefully put the pointer 2048 bytes before the end of the
  23. file.  The problem is of course: should the offset really be negative? I
  24. have two books about Gemdos which give two different answers to this
  25. simple question -- probably Murphy's law. 
  26.  
  27. Most of the device drivers existing for MiNT (procfs.c, shmfs.c,
  28. clockdev.c) assume that Fseek(offset,handle,2) will put the pointer
  29. "offset" bytes _before_ the end of the file.  Therefore, "offset" should
  30. be positive.  Ramfs also follows this convention.  Minixfs probably
  31. follows the opposite convention, since it works with stzip. 
  32.  
  33. [ We could make the program more bomb-proof by considering only the
  34. absolute magnitude of "offset"; but in ramfs you should also be able to
  35. seek past the end of a file, so it's not desirable. ]
  36.  
  37. Thierry.
  38.